問題描述
C# MVC：MVC Html Helpers 與視圖中直接 HTML 的性能和優勢 (C# MVC: Performance and Advantages of MVC Html Helpers vs. Direct HTML in views)
I'd like to know what kind of performance impact Html helpers have on C# ASP.NET MVC views, especially when setting attribute parameters, and what kind of advantages they have overall (why use them?)
With Html Helpers:
<%= Html.TextBox("firstName", Model.FirstName,
new { @disabled = "disabled", @class = "myCssClass" }) %>
Direct Html:
<input type="text" class="myCssClass" name="firstName"
disabled="disabled" text="<%= Model.FirstName %>"/>
I have quite a few pages that contain between 5 and 15 of such inputs. On top of that Html Helpers allow you to render the form (think Html.BeginForm()) etc. so you potentially end up with 20 or even more Html Helper calls. I think some of them use reflection too, e.g. when you set attributes like the disabled one above.
Isn't there a huge performance impact to do this? Why on earth is it considered better practice to use those helpers? Please somebody give me a good reason :) I'd like to use them but I really fear the performance impact they have.
Are there any real advantages to using Html helpers?
參考解法
方法 1:
The overhead of doing reflection is something that people really like to worry about. Outside of synthetic benchmarks, however, it becomes a pretty boring topic!
In the context of a real production application (where you are doing CRUD operations against a databases or consuming a webservice for example), the overhead of using html helpers is going to be insignificant compared to the overhead of doing that kind of context switch.
Really not something to worry about especially considering the benefits html helpers provide such as automatically restoring form values from ViewData/Model, and validation support.
Bottom line: use html helpers when possible. You can always use straight html if you encounter a rare limitation that you need to work around.
方法 2:
Are there any real advantages to using Html helpers?
The biggest advantage I see in using HtmlHelpers is to provide an abstraction layer for your markup. If in the future you wanted to change the structure of your markup you only need to change the output generated from the helpers, as opposed to going through all your views and making manual changes.
It also promotes consistency amongst teams of developers. Those developers aren't required to know the exact details of the markup structure and css classes your UI is based on.
As an example, I'm currently developing a new UI framework for the company I work for based on Bootstrap. I have created a set of HtmlHelpers that generate the appropriate markup and css classes for the various Bootstrap components. This is all done in a Fluent API which is nice for developers to use, without any in-depth knowledge required of Bootstrap, plus with the added benefit of having Intellisense available.
Telerik's Kendo UI framework is based on the same concept. Take a look at some of their code samples.
As for reflection and performance, I really wouldn't worry considering the number of calls likely to be involved in a few HtmlHelper methods. See this post for reasons why.
方法 3:
I've done it both ways, and the performance seems to be about the same. Phil Haack says you can do it either way -- that the helpers are just that, helpers, and if you prefer you can write Plain Old HTML.
I'm not sure that the helpers are any safer...either way you wind up with the same HTML in the web page...but the intellisense does seem to work better in the helpers for some reason, which is nice.
Dropdowns are easier to make with the helpers, since you don't have to spin up a loop for the selection list. Hidden fields and text boxes (and links as well) look better to my eye done in plain HTML, especially if they contain several attributes, as you are able to avoid that object initialization syntax.
Plain HTML appears to mesh well with jQuery (see here for an example). And the plain HTML is just easier to read.
I imagine helper methods being useful when you want to inject a larger structure into the html. In a few months you will find websites rich with these methods, that will support all kinds of functionality. Imagine being able to inject a graph into your page with one line of code.
方法 4:
There isn't any reflection with HtmlHelpers. The last parameter isn't an object, its a dictionary, so lookup of values is via hashtable, not reflection. The HtmlHelper is nice in that its methods are safe and secure...input is encoded where necessary, security checks are peformed where needed, etc. There is a lot more to HtmlHelpers than just html rendering.
方法 5:
Your controller action (invoked by GET) results in many cases must be cached to achieve good performance. So you should not worry about your View's execution time. For me it is hard to imagine a situation where your HtmlHelper's execution time may become the performance bottleneck.
(by Alex、James H、Brett Postin、Robert Harvey、jrista、eu-ge-ne)